A new style dialog is now used for merge points (ALT+M) options
FIX: Points more likely to remain selected after scale or lathe
Vehicle editor:
For flashing pit speed limiter light - choose brake or rear fog
Width / ratio / rim width move in bigger steps with right click
Frame position adjustments use expected steps for mouse clicks
Limited sidecar support:
Lone wheel (e.g. front) can be offset left (in Suspension tab)
- offset wheel to right is currently disabled for compatibility
Pair of wheels (e.g. rear) can be longitudinally staggered
- only the rearmost wheel of a staggered pair is driven
- anti-roll is disabled when the pair is staggered
NOTE: You also need LFS test patch D25 for:
- one-wheel-drive sidecars
- pit speed limiter flashing light using fog light
No, the idea of this change is that these options are individually selectable per vehicle, instead of being controlled by the race class.
Previously, the flashing light was enabled by F1 class, but now it is set by its own switch. You do need LFS Test Patch D24 to see the effect of the new switch, or it will still be controlled by the race class.
Interesting thought but it won't be in this round of test patches. Everything I do in the current public version must be merged into the separate development version, which isn't always easy. Also any changes in the core of the physics system are likely to invalidate all the hotlaps, which isn't worth doing at the moment. Also, incompatible setups, online compatibility, interface updates, etc...
I look forward to releasing the development version, so we only have one version and it will be much easier to add new features then.
Thanks for that. The offset seems to be inside LFS and it is reading a block of memory from a file.
From the information available, it's not possible to know which code was calling that function at the time.
As no-one else has reported this bug, I am wondering if it could be a corrupted mod file on your hard drive. Corrupted files are rare but it can happen. There is one way to test this. I don't know how much you like this idea but if you would rename your mods folder to something else (or delete it) then you will download mods fresh again.
That doesn't explain why D21 crashed and D20 didn't. According to this theory, any available version would crash if someone on the server was using the mod that is corrupted on your hard drive.
If it's OK with you, I'd be grateful if you would try this test because if the problem doesn't come up again that could mean it really was a corrupted file issue, and not something I should look into right now.
Thanks for the report. This has happened as the mod failed an upload check, due to a new upload checker that I put in place. It's not that anything is really wrong with the upload checker, but when people don't use a recent editor test patch to export their mod, it's possible for this issue to come up due to issues in their old version of the editor.
Then, when that does happen, the website doesn't really do the right thing, as you noticed.
I've notified Victor to see what he can do on his side, and also I've reinstated the original upload checker so this doesn't keep happening right now.
I will now notify the uploaders of a few mods that have gone wrong in this way since yesterday.
The mod upload checker has been updated to a new version.
I recommend that mod creators should use the latest test patch, to avoid any inconsistency with the upload checker.
EDIT: I have now reverted to the original mod checker. Although now there is nothing wrong with the new one, there can be inconsistencies when mod creators don't use a recent update of the editor. This is too often the case, so it isn't yet the best time to use the new mod checker.
Sorry about that. I don't yet know how it could have gone wrong in that way.
I have reinstated the old veh checker on the server. Please try editor D23 and let me know if it works (also, D21 or others should be OK).
Only D22 should *not* be OK, because it does save the subobject names, which will fail on the reverted veh checker.
D23 *does* save subobject names if you share for development, but not if you export for submission. So that should solve the issue that kenblock30 reported, in a more specific way.
Now I'll try to figure out why the new veh checker didn't work as expected.
EDIT: (4 May 11:03 UTC) I found out why the veh checker didn't work. I have made the necessary change and tested it manually. I have put a new version there, which hopefully causes no problems (and should allow use of editor D22).
EDIT2: (4 May 12:38 UTC) I've reinstated the old veh checker again as there is some other error that I can't understand yet.
EDIT3: (4 May 13:46 UTC) I found out why the 2nd new veh checker didn't work. It was a completely different issue from the 1st new checker's problem. I have made the necessary change and tested it manually and also by doing a test submission of a private mod. I have put a new version there, which hopefully causes no problems (and should allow use of editor D22).
The LFS developers should host instructions on how to reverse engineer someone's software without their permission?
Honestly, I'm not even sure programs should be allowed to work the way LFS Lazy does, hacking into LFS. But it was allowed in this case, so that is beside the point.
I've added a couple of the most requested features from LFS Lazy into a recent test patch.
I know there are many other features of Lazy that are still wanted, though I assume you would prefer me to to continue working on the new tyre physics, instead of trying to implement the features of LFS Lazy?
It's possible to recreate many of the features of LFS Lazy without resorting to hacking obsolete software which is itself a hack, even if a very good one. I mentioned above, the PACT Driving Assistant which is currently in development has many features that may be of interest (although I don't know which features of LFS Lazy can or cannot be done by PACT).
I've received another South City update from Eric so did a few track editor updates that were relevant at this point. In the process I updated a few features from the public editor, so here they are.
Editor Test Patch D19:
Hotkey for "hide/unhide (un)selected" changed from X to H (like blender)
- small H button at top left to hide/show message history (old H function)
Left click increments should now always be smaller than right click
- previously this was not consistent for all types of buttons
- as before, CTRL may do smaller steps, SHIFT may do larger steps
- this change should apply to distance, colour, angle and scale
Find button for error triangles or points now selects all as expected
- previously only selected the first point or triangle in the list
I did spend a lot of time last month on test patch and editor updates, but that's not my focus now. I won't go into all the reasons why that happened, but there was an important update, then I saw the E-Challenge, saw something that could be improved there, thought of a few other useful improvements, one thing lead to another...
Not a problem, that's all good. The updates were significant and important.
The idea of the progress reports wasn't really "this is what I will do forever". It was an insight into the development process, and I went into extreme detail, maybe even too personal, so people could really understand what being a programmer is about.
Tyre physics doesn't go the way multithreading goes. For me, it's not really suitable for rapid progress reports. There's a lot of experimentation and testing, research and hard thinking.
However much you want the new version released, multiply that by 100 (rough estimate) and that's how much I want it released. The new version is what I work on and think about for many hours every day. All I can really say at this point is don't worry, I'm on it.
Here's another update. Hopefully you should find it is more tolerant with bad normals (finds less normals to be bad) and more informative about small or thin triangles that can cause bad normals.
Merge by distance can now be used over a whole mesh and instead of aborting after 12 seconds, it shows progress every second so you can stop it if you want.
Editor Test Patch D18:
New function "invert" to invert selection (selected - unselected)
Point merge options now on one line and includes distance merge
Improved merge by distance to update every second if merge is long
- you can watch the progress and stop at any time by pressing ESC
Improved handling of bad normals and some of the reasons for them
- triangles that are too small or too thin are separately listed
- triangles as small as 1/3 of a millimetre can contribute normals
I'm short of time today but added a couple of features that make yesterday's model error reporting more useful.
New 'find' buttons to select error triangles or bad normals
New button to select a point by entering the point index
Index of a single selected point or triangle is displayed
Rearranged buttons in tri mode to line up with point mode
Spare wheel can now be offset laterally (set RIGHT value)
FIX: Save as SIT / STR name now limited to 7 characters
FIX: Dashboard texture can now be updated in a 2D view
Modeller:
Removed message spam about bad normals - instead a report is displayed at the top right in the modeller. This feature is not yet finished as I would like to add a button to help by selecting one of the offending points or triangles.
I just found out that I can allow the spare wheel to be offset, with no compatibility issues. I hope to release an editor test patch today or tomorrow. I'll check your bug reports thread as well.
1) Vehicle editor will not crash (in Textures tab or when creating car from model)
2) There is a message "Too many materials"
3) It will not export for testing or upload if there are too many materials
This must be the best way, as LFS itself will crash if there are too many materials. I believe there should be no need for so many materials, if you can share texture pages, etc.
Is there a simple step-by-step way I could reproduce this? Maybe starting from an LFS vehicle, or a test vehicle you could provide?
Based on your description, I added a new texture page, cutout, mapping and triangle, exited back to vehicle editor but didn't get a crash with the Textures tab open.
But if I can reproduce the crash then I can fix it, that's for sure.
Some people have always experienced very slow mod downloads. We are interested to find out why that is.
By the way, Test Patch D20 works with our web server to download mods from USA or Japan if you are in America/Asia/Oceania, which appears to work well for those who have tested it.
But geographical distance doesn't explain the extremely slow downloads that some people have experienced. If you do get that, we may get a clue from MTR (My Traceroute) results, if you could post them in this thread:
Hi texxxas, if your location is Poland then I don't think you'll get any benefit from the new D20 redirection system. If you always get slow downloads, we might get some a clue if you could try a MTR (My Traceroute) from your location.
Thanks for the MTR results (not that I know what do do with it).
Maybe the Rotterdam one could be useful if it gives a clue why ordinary downloads are slow for you.
I got the Rotterdam IP from 'ping lfs.net' : 188.122.74.149
It's a funny thing, the 'extremely slow downloads for some people' issue. Yesterday I used a VPN to do LFS downloads via a server in Japan. One reason: to test redirected downloads from Japan. But, on topic, I also ran 0.7D (no redirection) over the VPN to download mods from Rotterdam via Japan, and it's (of course) slower than usual but still quick, just a few seconds for a mod, nothing like these reported several minute downloads. It makes me think that geographical distance isn't the main reason, and it must be something to do with people's internet connections, due to their ISP or country connections.
Victor mentioned MTR (My Traceroute) above and has done to me before. Maybe we could get a clue, from people who experience super-slow in-game downloads, MTR results to these IP addresses:
188.122.74.149 - NL
103.194.164.52 - JP
162.244.55.54 - US